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Research Aspects of Rapid Prototyping 



1. Research Summary 

The objectives of the proposed research are to develop specification methods 
for identifying and retrieving reusable software components, to develop imple- 
mentation techniques for the prototyping language PSDL, and to extend the 
language and techniques to a multiprocessor model for the prototype. 

Our approach to component specifications will be based on term rewriting 
systems and the concept of generalization per category. We will seek coinponent 
specifications that admit effective reductions to a canonical or normal form to 
aid component retrieval. The attributes of reusable software components will be 
abstracted to support the design of a software base schema, which will be struc- 
tured using generalization per category to aid component retrieval. The relation 
between the specification language and the software base oper^ors will be esta- 
blished. Experimental conditions for testing the results will be established 
through the experimental generation of a series of translators for the prototyping 
language PSDL with the aid of an attribute grammar based translation tool. 
We"^ will also seek efficient interpretive techniques for impleinenting PSDL, 
extend the language to include scheduling constraints due to distributed external 
systems, and develop suitable multiprocessor scheduling algorithms. 

The proposed research will solve some key problems in automated prototyp- 
ing based on reusable software. Validating software requirements by rapid pro- 
totyping depends on three major components: a prototyping language, a 

software base, and a prototyping method. The objectives of the proposed 
research contribute to the software base and the prototyping language. 



2. Research Description 

Finding effective and efficient methods for determining and validating the 
requirements for a software system is an important unsolved problem in software 
engineering. Prototyping is a promising approach for requirements validation. 
Current prototyping methods require an impractical amount of time and effort. 
The objective of the proposed research is to make automated rapid prototyping 
possible. 



2.1. Objectives and Significance 



The rapidly growing demand for software has shifted towards larger systems 
and higher quality software, to the point where current software development 
methods are inadequate. A jump in software technology is needed to improve 
programming productivity and the reliability of the software product. Rapid 
prototyping is one of the most promising methods proposed to reach tnis goal. 

A prototype is an executable model or a pilot version of the intended sys- 
tem. A prototype is usually a partial representation of the intended system, 
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used as an aid in analysis and design rather than as production software. The 
construction activity leading to such a prototype is called rapid prototyping. 
Rapid prototyping has been found to be an effective technique for clarifying 
requirements and eliminating the large amount of wasted effort currently spent 
on developing software to meet incorrect or inappropriate requirements in tradi- 
tional software life cycks[l]. A key issue in the design of large software systems 
is how to agree on the requirements. Lack of agreement on the requirements as 
specified by the customer and as analyzed by the designer causes inconsistencies 
between the delivered system and customer expectations, leading to expensive 
rebuilding[l]. This problem is especially acute for large systems and systems 
with real-time constraints because the requirements for such systems are compli- 
cated to describe and difficult to understand. Because the user can usually 
recognize whether or not a working software system does what is needed, but 
usually can’t describe the requirements accurately, prototypes are an effective 
means for achieving stable and accurate requirements early in the development 
process. 

A prototype can also be used to specify a well modularized skeleton design 
for the intended system and to validate the important attributes of the intended 
system, e.g. timing constraints, input and output formats, or interfaces between 
modules. Rapid prototyping is a useful tool in feasibility studies. Prototypes of 
critical subsystems or difficult parts of a complicated system can significantly 
increase the confidence that the system can be built before large amounts of 
effort and expense are committed to the project. Rapid prototyping helps in 
estimating costs, since the cost of the intended system is usually proportional to 
the cost of the prototype. The experiences gained in applying rapid prototyping 
to special applications, e.g. database design, metaprogramming methods and 
translator design, have substantiated this cost relationship between the proto- 
type and the completed system[2-4]. 

Software tools are needed to make rapid prototyping practical. An initial 
description of a framework for a rapid prototyping environment based on reusa- 
bility can be found in[5j. Since automatic program generation from very high 
level specifications is not yet practical, reusing existing system components 
appears to be the most economical approach for constructing prototypes. An 
important problem in reusable software is finding the relevant software com- 
ponents, because the retrieval must take less effort than constructing the com- 
ponents for this approach to be practical. We propose to develop methods for 
organizing a software base to aid interactive retrieval of reusable components, 
and to seek better automated methods for component retrieval. Another impor- 
tant problem is tailoring and connecting the reusable components into a higher 
level assembly. We believe the best way to do this is by using a language 
expressly designed for the purpose, and we have designed such a language 
(PSDL). We propose to investigate efficient ways to implement this prototyping 
language. 



2.2. Relation to Long Term Work 

Our long term goal is to enable the construction of a highly automated 
software engineering environment supporting a development method for large 
real-time systems based on rapid prototyping. The proposed research addresses 



3 



some key steps in our approach towards this goal. 

We use an integrated approach to prototyping that combines a computa- 
tional model tailored for describing real-time systems with a high level prototyp- 
ing language PSDL [6], a systematic design method for rapid construction of 
prototypes[7,8], and an automated prototyping environment with a software 
base[9] containing a large set of reusable software components. The computa- 
tional model has been designed to prevent hidden interactions between system 
components, to encourage designs with good module independence. The 
language supports the model and combines it with a powerful set of data and 
control abstractions to make it easy to describe system at a high level. The 
automated environment relies on a software base management system for 
retrieving and adapting reusable software components, a syntax directed editor 
for speeding up design entry and preventing syntax errors, and an execution sup- 
port system for demonstrating and measuring prototype behavior and for per- 
forming static analyses of the prototype design. 

Rapid construction of a prototype in PSDL is made possible by the associ- 
ated prototyping method and support environment. The prototyping method 
relies on an improved modularization technique and reusable software com- 
ponents. The support environment reduces the efforts of the analyst and 
designer by automating some of the tasks involved in prototype construction. 
The most important aspects of the support environment are the software base, 
the prototype execution facilities, and the design entry facilities. 

2.2.1. The Prototyping L;»nguage PSDL 

A good language for expressing design thoughts in terms of a precise model 
is important for rapid prototyping. It is impossible to do a good design without 
a language especially designed for this purpose. A powerful, easy to use, and 
portable prototype description language is also a critical part of an automated 
rapid prototyping environment. Such a language is needed before the tools in 
the environment can be built. PSDL (Prototype System Description Language) 
was designed to serve as an executable prototyping language working at a 
specification or a design level[6], together with a prototyping method and an 
automated support environment. The language has special features particularly 
appropriate for real-time system design. PSDL prototypes are especially well 
suited for requirements analysis and validation because they are executable and 
are specified at a high level with requirements tracing. 

PSDL [10] and its prototyping method are concerned primarily with hard 
real-time systems. A hard real-time constraint is a bound on the response time 
of a process or the period between invocations that must be satisfied under all 
operating conditions. hard real-time system[ll] ha.s hard real-time constraints 
as part of its requirements. Such systems are modeled in PSDL as networks of 
operators communicating via data streams, which uses enhanced data flow 
diagrams for that purpose. The data streams can carry data values of an 
abstract data type[l2| as well as tokens representing exception conditions. Each 
type or operator is either composite or atomic. Composite operators are imple- 
mented by decomposing them into networks of more primitive operators using 
PSDL. The decomposition of a composite operator is described in PSDL by an 
enhanced data flow diagram that includes non-procedural control constraints 
and timing constraints. Atomic operators are realized by retrieving an 
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implementation from a software base[9,13] containing reusable software com- 
ponents. 

PSDL provides sufficient structures and descriptive ability to describe the 
internal and external situation for the modules comprising the system. Good 
modularity is one of the key factors for increasing productivity, since it 
significantly reduces the debugging effort for producing a correct executable sys- 
tem, and also influences the understandability, reliability, and maintainability of 
the developed system, which are especially important in rapid prototyping. A 
clear and powerful modularization model is introduced in PSDL for building and 
describing the prototype. .The model is based on data flow under real-time con- 
straints. This model and the associated prototyping method[7,8], lead to PSDL 
prototypes with a highly cohesive structure and few coupling problems. This 
structure is suitable for multiple modifications at a specification level during the 
prototyping iterations of the new life cycle. 

A PSDL prototype is useful for checking real-time requirements because the 
critical timing constraints and the most important concerns, e.g. maximum exe- 
cution time, minimum response time, and synchronization, are very hard to vali- 
date without actually constructing a valid schedule and observing the execution 
of the prototype. Most real-time systems are used to monitor and control physi- 
cal processes external to the computer in an embedded system. The precision 
and accuracy requirements in the design of a real-time control system complicate 
the demands on the execution of the designed software system. For these rea- 
sons, the design of real-time systems imposes particularly stringent demands on 
a prototyping language. The formal structure in PSDL specifying the real-time 
constraints provides a basis for automating the production of code from the for- 
mal requirements specifications to the underlying programming language. The 
execution of PSDL prototypes helps to verify that the design of an embedded 
system with given timing constraints for the components in the prototype will 
interact with its environment in a way that meets the timing constraints of the 
system as a whole. This is important because making a production quality 
implementation is very expensive, so that it is desirable to check that a design is 
feasible by using an inexpensive prototype before committing significant 
resources to an implementation. 

2.2.2. The PSDL Prototyping Method 

In the rapid prototyping paradigm, the traditional software life cycle used 
in software design is replaced by a recently proposed alternative life cycle which 
consists of two phases: rapid prototyping and automatic program generation [5]. 
Completely automatic generation of programs from very high level specifications 
is not currently practical. In our approach, program construction is sped up by 
taking advantage of reusable software components drawn from a software base. 
The aspects of program construction that benefit from mechanical assistance are 
retrievals from the software base, generation of code for interconnecting avail- 
able modules, and static task scheduling. 

In rapid prototyping the prototype is used in an iterative process of negotia- 
tion. The user describes the requirements, and the analyst interprets them and 
builds a prototype. The analyst then demonstrates the execution of the proto- 
type to the customer. The requirements are adjusted based on feedback from 
the customer, and the prototype is modified accordingly until both the customer 
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and the analyst agree on the requirements. This process is illustrated below. 



+- 




- + 


H 


-H- 


1 


de t e rmi ne 


1 requir emen t s 


1 c on s t rue t 


1 


1 


r e qu i r emen t s 


1 > 


1 prototype 


1 


+- 


- + 


+ 


- + 



I requirements adjustment 

-I \- 

I demonstrate I * 

I prototype | 

-I 4- requir erne n t s OK 



prototype 

V -f- 

+ - > I s y s t em 
-->1 implementation 
+ 



Rapid prototyping is particularly effective for ensuring that the require- 
ments accurately reflect the real needs of the user, increasing reliability and 
reducing costly requirements changes. PSDL was developed together with a 
method for rapidly constructing prototypes for large systems with real-time con- 
straints. The purpose of the PSDL prototyping method and its support environ- 
ment is the rapid construction of executable prototypes for large real-time sys- 
tems with the following properties. 

(1) The prototype must satisfy and be traceable to its requirements. 
Iterated prototype construction is used to analyze and firm up the 
requirements for the intended system. 

(2) The prototype must be easy to modify. The prototype will be subject to 
many revisions before the user is satisfied with the requirements as 
reflected by the behavior of the prototype. 

(3) The prototype must be easy to read and analyze. The prototype serves 
to document an initial design, and to support analysis of the intended 
system. Clarity and simple high level structures allow designers to easily 
answer questions about the properties and the feasibility of the intended 
system based on the prototype. 

The goal in constructing a rapid prototype is different than in constructing a 
production quality software system. Efficient use of designer time and rapid 
feedback for the user are more important than robust operation, efficient use of 
machine resources, or completeness. 

A problem oriented top-down strategy is used to focus the prototyping 
effort on critical problems or selected attributes of the entire system. The major 
system attributes that must be demonstrated to the user usually appear in a 
critical subsystem. It is necessary to create a quick sketch of the skeleton of the 
intended system, because the environment of the critical subsystem must be at 
least partially simulated to demonstrate the behavior of the prototype. This 
quick sketch can be built rapidly and understood easily by means of a highly 
interactive graphics editor for PSDL. The essential advantage of rapidly build- 
ing the sketch of the prototype is that it provides an initial description of the 
intended system, which can serve as the basis to analysis and negotiation. The 
prototype system gradually fulfills the requirements during the iterations of the 
prototyping effort [6]. Our prototyping method enables each update to the proto- 
type to be made quickly and easily. 
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The PSDL prototyping method results in a hierarchically structured proto- 
type. The method provides a hierarchical decomposition strategy for filling in 
more details at any level of the prototype design. It also helps the designer to 
concentrate on the critical subsystems that must be refined to resolve the prob- 
lems that motivated the rapid prototyping effort. The prototyping method uses 
stepwise refinement to selectively refine and decompose critical components. 
Each higher level component is described in terms of lower level ones and the 
relations between them. The decomposition of each composite component is a 
realization of the system at a lower level of detail. 

The prototype is designed based on abstract functions, abstract data, and 
abstract control. This high level view emphasizes the overall configuration at 
each level without getting bogged down in programming level details. The 
design is refined by decomposing abstract functions and data types into lower 
level ones. Functional, data, and control abstractions are used to hide lower 
level details, effectively carrying out the recommendations in[l4]. Control con- 
straints are combined with the data flow model to achieve the best modularity 
with sufficient control information. Data flow is used to simplify the interactions 
between modules, eliminating direct external references and communication by 
means of side effects. 

2.2.3. The Rapid Prototyping Environment 

An automated support environment is essential for the rapid construction of 
prototypes. PSDL and its prototyping method have been designed for use in an 
environment containing a software base management system, an execution sup- 
port system, a syntax directed editor with graphics capabilities, and a design 
database. 

2. 2. 3.1. Software Base 



The software base management system[l3] is responsible for organizing, 
retrieving, and instantiating reusable software components from the software 
base, while the design database is responsible for managing the versions and 
alternatives of the prototype design, as illustrated in the following diagram. 
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Prototyping Approach 

A software base management system should support the retrieval of the set of 
software components whose specifications match a given template. The reusable 
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components in the software base are used to realize subsystems of the prototype, 
and the available reusable components are used to guide the decomposition pro- 
cess by which the behavior of the prototype is refined. PSDL is used to describe 
the connections between the components of a prototype, and to specify the 
behavior of the reusable components in the prototype as well as those in the 
software base. In addition to implementation information, each component in 
the software base must have a PSDL specification. The PSDL specification is 
organized as a set of orthogonal attributes. Component retrieval based on par- 
tial matches of specified subsets of these attributes must be provided by the 
software base management system. A browsing capabilityflS] and a set of 
operators for tailoring and instantiating generic components[9] should also be 
provided. The browsing capability is important because it can give the designer 
guidance on how to decompose a prototype to best take advantage of the avail- 
able reusable components. The operators are important because it is impossible 
to explicitly store all possibly relevant variations on each reusable component. 
We believe it is possible to find a manageable set of generic components and 
adapting operators sufficient to cover most of the variations needed in rapid pro- 
totyping. Establishing this is one of our research goals. 

A sufficiently large practical software base containing high quality reusable 
components is needed. It is important to have a relatively complete set of gen- 
eral purpose components for performing the functions that are common to many 
systems, such as managing displays, sorting and searching, parsing input strings, 
and managing lookup tables. Many of these functions can be effectively encap- 
sulated in a relatively small set of abstract data types, such as those described 
in[l5]. It is very important to provide generic versions of the reusable com- 
ponents, since it would otherwise be impossible to design with abstract data 
types while relying on standard reusable components for performing common 
utility functions. 

The advantages of a set of general purpose utility modules that can ecisily 
be used together in various combinations has been well established by the early 
work on the Unix Programmer’s Workbench[l6]. This work relied on a single 
interface format, namely an ascii text file, to ensure compatibility between the 
various tool interfaces. Such an approach works for applications dominated by 
text processing, but restricting interfaces to any single data type is unacceptably 
restrictive for prototyping large software systems. We solve the compatibility 
problem by requiring the utilities to be polymorphic operators, i.e. parameterized 
families of closely related operators [17]. An example of a generic reusable com- 
ponent used in this way is shown below. 
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In this example, A and B are special purpose modules realized by the designer 
using PSDL, and sort [flight] is an instance of a generic reusable component from 
the software base. The sort operator can be applied to sequences containing ele- 
ments of any fixed type that provides a less operation for comparing two 
instances of the type. The type of the elements in the sequence is specified by a 
generic parameter, and is bound to the abstract type flight on retrieval from the 
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software base. 

Polymorphic operators can be realized using the generic packages of Ada, 
where the types of the inputs and outputs are supplied as generic parameters. 
These operators can be connected to any other components, because the input 
and output types of the utility operator can be adjusted to fit the interfaces of 
the modules it will be connected to. Note that generic parameters are required 
because no fixed set of interface types is sufficient to accommodate all of the 
abstract data types that might be defined by a designer in future applications, 
and even a large software base must be finite. This makes Ada a good choice for 
the underlying programming language. 

2. 2. 3. 2. Execution Support System 

In order to construct and update a prototype rapidly, the execution support 
system for PSDL must be efficient. Since prototype modifications are at least as 
frequent as prototype runs in the expected usage pattern for the execution sup- 
port system, both preprocessing time and execution time must be given roughly 
equal weight, making an interpretive implementation strategy preferable to com- 
pilation. 

The execution support system should be able to save the state of a compu- 
tation, and to run several alternative versions of a prototype from a given state 
without repeating the initial part of the computation. This is important because 
the designer will be engaged in an interactive dialogue with the user, where a 
given aspect of a prototype's behavior is demonstrated, criticized, and alterna- 
tives are explored interactively. Since it may have taken a long user interaction 
to arrive at the particular state to be examined, it is not acceptable to require 
the designer and the user to go through many repetitions of that dialogue, or 
even to incur the delay due to re-running the initial part of the dialogue from a 
saved script. The need for modifying the prototype in the middle of a run 
implies the need for a dynamic loader that can be used in the middle of a given 
execution of the prototype, and for some means for rapidly responding to 
changed specifications for a component of the prototype. This motivates the 
need for a high quality software base of sufficient size to accommodate most 
common variations on system behavior and a powerful software base manage- 
ment system capable of retrieving reusable components efficiently. 

The execution support system consists of a static scheduler, a dynamic 
scheduler, and a debugger. An initial design for these components is described 
in[l8]. The purpose of the static scheduler is to schedule time for the computa- 
tions with hard real-time constraints in such a way that all of the timing con- 
straints will be guaranteed to be met. We use the standard approach of stati- 
cally allocating time slots sufficient for the worst case execution times of the 
operators. The abstract treatment of timing information is an important pro- 
perty of the data flow model since only the essential time orderings among the 
events in the computation are given. These time orderings act as constraints on 
the static scheduler, and allow the fiexible exploration of schedulers for multi- 
processor configurations. The purpose of the dynamic scheduler is to utilize time 
slots not needed the time critical computations to schedule the computations 
that do not have hard real-time constraints. The purpose of the debugger is to 
exercise the prototype, to collect statistics, and to enable the designer to readily 
modify the prototype to conform to new or modified requirements. 
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2. 2. 3. 3. Designer Interface 



The proposed designer interface consists of a syntax directed editor for 
PSDL and a graphics tool for constructing and displaying data flow diagrams. 
The syntax directed editor helps to speed up the process by eliminating syntax 
errors, automatically supplying keywords, and prompting the designer with a 
choice of legal syntactic alternatives at each point. The graphics tool is a part of 
the syntajc directed editor, whose purpose is to provide a graphical view of the 
dataflow diagram part of the PSDL implementation of a composite module. 
The graphics tool helps the designer visualize the relationships between the com- 
ponents of a decomposition by means of a two dimensional data flow diagram, 
and provides a convenient way to enter and update the decomposition informa- 
tion in the enhanced data flow diagram, which is part of a PSDL implementa- 
tion of a component. This capability is important because the text form of a 
data flow diagram is harder to understand than the graphics form. 

2. 2. 3. 4. Design Database 

The design database[l9] in the prototyping environment contains a PSDL 
design and a set of requirements. The most important function of the design 
database is to manage and record the refinements and alternatives that were 
considered in the prototyping effort. This is especially important in prototyping 
because it is an exploratory activity, in which insights gained in later 
refinements often shed new light on the problem and make previously rejected 
design alternatives look attractive again. The design database should provide 
facilities for backtracking to previous stages, and for combining different deci- 
sions that were made along different alternatives in the development [20]. 

Using a database rather than a text file also simplifies job of writing pro- 
grams that analyze PSDL prototypes, and helps to provide a continuous cross 
referencing capability, by maintaining binary relations between pairs of syntactic 
objects. Examples of syntactic objects include individual requirements and indi- 
vidual software components. The cross referencing capability is most important 
for requirements tracing, and is used mostly in updating the requirements and 
adjusting the prototype to match. The binary relationship relevant to cross 
referencing is satisfies-requirement. The design database must support retrievals 
of the forms 

(1) given a requirement, find all the PSDL components that realize it, zmd 

(2) given a PSDL component, find all of the requirements it realizes 
to effectively support prototype modification. 



2.3. Relation to Previous Work 



The proposed work is related to earlier work in five main areas: rapid proto- 
typing, design methods, specification and design languages, modeling of real- 
time systems, and reusable software. 
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2.3.1. Rapid Prototyping 



Prototyping has become increasingly popular in system development [21]. 
There is a popular branch of rapid prototyping work aimed at database applica- 
tions [2]. Several approaches are based on programming languages [16, 22]. These 
systems do not link very well to user requirements, and do not address real-time 
constraints. SREM[23] is a pioneering piece of work on the use of prototypes for 
validating requirements. This work addresses real-time constraints, machine 
assisted generation of simulations, and tracing aspects of a simulation to user 
requirements. However, SREM does not support abstractions and hierarchical 
decompositions very well. PAISLey[24] addresses the operational specification of 
real-time systems. Other work on executable specifications has concentrated on 
transforming specifications into run-time checks for detecting specification viola- 
tions[25]. This work is still far from the automatic transformation of 
specifications into running systems. 

There has been a fair amount of work on machine aided rapid prototyping 
for systems without hard real-time constraints. [26] describes a system for proto- 
typing user interfaces for interactive systems. [27] uses Petri nets to prototype the 
synchronization and interprocess communication aspects of process control sys- 
tems. While the notation is not very easy to read, it does support automated 
deadlock detection and performance evaluation in terms of steady state probabil- 
ities for graph markings. [28] describes a system for prototyping data processing 
applications. While they have a tool for determining delay times of modules, 
they do not describe a method for designing systems with real-time constraints, 
nor do they support data abstractions, making their approach cumbersome for 
complex systems. 

2.3.2. Design Methods 

The important problems facing the computer software industry are achiev- 
ing cost effective production of software systems and increasing the quality of 
software products with respect to meeting user requirements. Many software 
development methodologies have been proposed to approach this goal. Most of 
the well-known ones, such as Object Oriented Design (OOD)[29,30] and the 
Jackson System Development Method (JSD) [31,32] more or less depend on the 
skill of individual designers at the level of manual work. [32] describes a tech- 
nique for modeling real world systems which is appropriate for typical data pro- 
cessing applications. This method does not address real-time constraints and is 
weak on data abstractions. These methods are labor intensive, and are too 
informal to guarantee any quality standards for the resulting design. They are 
unlikely to lead to any significant improvements in the reliability of software 
products. 

Newly proposed software tools for software design, such as GENESIS [33], 
SREM[23], the PAISLey operational approach[24], and DIANA[34] go one step 
further. Most of them are really software development environments consisting 
of many software tools for computer-aided software development. Some of them 
are designed to fit specific needs, e.g. DIANA is a tool for the design of Ada sys- 
tems. Even if we consider only the prototyping aspects of these tools, it is clear 
that complete automation of software development is still a distant goal. Most 
of these types of tools cannot be extended to the point of complete automation 
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because of the lack of mathematical formalization in the related theoretical fields 
of software engineering. 

Two kinds of software system decompositions have been identified[35,36j, 
one based on data flow and the other based on control flow. [35] suggests cir- 
cumstances in which each of the two kinds of decomposition is preferable and 
give some restrictions sufficient to guarantee that the computed results are 
independent of scheduling decisions, but does not address real-time constraints. 
The method amounts to choosing either a data flow decomposition or a control 
flow decomposition at each level, depending on the circumstances. It is difficult 
to follow all the confusing restrictions given in these papers and to understand 
the overall idea since they do not provide a good computational model and their 
system is intended for lower level applications. 

2.3.3. Specification and Design Languages 



A prototyping language must have the characteristics of a good design 
language, because the structure of a prototype must be understandable and easy 
to modify. Early design languages[37,38[ were not executable, although more 
recent work has promise in this direction[39j. These languages do not support 
real-time constraints or requirements tracing. Some design languages address 
the design and specification levels, but are not executable[40j. Languages for 
specifying real-time systems have also been investigated[41-43j. 

A number of non-procedural programming languages have been pro- 
posed[43,44j. These languages nave the advantage of being easy to analyze, and 
of exposing the natural parallelism in an algorithm. The design of the non- 
procedural control constraints of PSDL owes much to these ideas. One 
difference between our worK and previous approaches to rapid prototyping using 
applicative languages [24. 45] is that we provide a black box specification for each 
component in addition to a non-procedural implementation. Black box 
specifications are important because they separate required properties of the pro- 
totype from the incidental ones, and because they can be used for retrieving 
reusable components from a software base. 

Many informal versions of data flow diagrams[46,47] have been used exten- 
sively to model the data transformation aspects of software systems. Data flow 
diagrams are easy to read, revealing the internal structure of a process and the 
potential parallelism inherent in a design. The automatic drawing of data flow 
diagrams is a practical step towards design automation using data flow 
diagrams[48]. The use of a convenient graphical form makes data flow attractive 
to many designers because it reveals the structure of the design in an easily 
understandable form. We believe an automated prototyping environment 
should provide graphical capabilities for displaying and updating the system 
structure of the prototype. 

However, these informal notations do not provide a unified mechanism lo 
represent all of the relevant attributes of software systems (e.g. timing and con- 
trol[49]) and are not sufficiently formal to be executable. A more precise model 
of a data flow computation has been developed in the context of hardware 
design[50]. We have extended the model and the notation to include control 
aspects and critical timing constraints in a two dimensional data flow diagram 
without losing its natural benefits. These extensions are needed for the design of 
systems with hard real-time constraints. 
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2.3.4. Real-Time System Modeling 



Attempts to use data flow diagrams for modeling real-time systems [49] have 
resulted in complicated low level models that reflect only qualitative rather than 
quantitative information. Some of the work on modeling real-time systems has 
focused on the scheduling problems associated with real-time constraints [11, 5 ij. 
These results are important for execution of PSDL prototypes. The application 
of these ideas to PSDL is described in[l8j. In[52], an analysis of hard real-time 
systems as well as scheduling policies for a single processor are provided. 

2.3.5. Reusable Software and the Software Base 

Methods for enhancing the reusability of software[5,53] are important for 
managing the software base[9,13|, which is one of the building blocks used in our 
work. 



2.4. General Work Plan 

The proposed directions for research include better techniques for retrieving 
reusable software components from a software base and more efficient 
approaches for implementing the execution support system. 

2.4.1. Software Base Retrievals 

Better methods for organizing and retrieving reusable components from the 
software base are important because the software base can effectively speed up 
the prototyping effort only if the fraction of successful retrievals is relatively 
high. We propose to investigate software base organizations based on adaptive 
generalization hierarchies, reusable component retrieval based on specifications 
with a semantic canonical or normal form, and techniques for combining pro- 
gram synthesis with software base retrievals based on partial matches. 

Generalization hierarchies have been found to be effective for supporting 
browsing tools [15], and have also been effective as knowledge representation 
tools in artificial intelligence applications. We believe that generalization hierar- 
chies are useful for two different purposes in the context of software base 
retrievals. First, a properly designed generalization structure should be a 
significant aid for interactive retrieval of components, especially for the process 
of looking for relevant components before deciding how to decompose a compo- 
site PSDL operator. Second, the hierarchy can be used to provide a basis for 
approximate retrievals when there is no exact match in the database. 

Generalization per category is a database organization principle that was 
recently developed for organizing parts libraries in VLSI design[54]. Generaliza- 
tion per category differs from conventional generalization because the specializa- 
tions of a general concept are disjoint and indexed by values of a categorical pro- 
perty. We believe that a disjoint categorization for reusable software com- 
ponents would be a very valuable aid to understanding and organizing a 
software base, and that such an organization is an important first step towards 
computer aided retrievals of the set of components relevant to decomposing a 
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composite operator. Working out such a categorization is therefore one of the 
goals of our proposed research. It has been conjectured [19] that a categorization 
with overlapping categories is a sign of a missing categorical property, and that 
it is always possible to find a natural categorical property that will rearrange an 
overlapping categorization into a disjoint one. No counter-examples to this con- 
jecture have been found, leading us to believe that it should be possible to find a 
disjoint categorization for software components. We also believe that working 
out such a categorization should provide some insights for constructing an algo- 
rithm for automatically retrieving a useful approximation to the set of relevant 
components, which is another goal of the proposed research. Generalization per 
category induces a lattice structure which can be exploited for efficient database 
organization. We propose to investigate the application of this structure to the 
design of an architecture for the software base. 

A special purpose prototyping language such as PSDL must be simultane- 
ously suitable for component specification and for use as a query language in the 
software base. These are conflicting requirements, because a specification 
language that is easy for people to use will have a rich set of primitives, which 
allow many syntactically different ways to describe the same function, while 
software base (or database) retrievals work best in situations where each indivi- 
dual has a unique identifier or key. We propose to investigate specification for- 
malisms with effectively computable canonical forms for specifications. 
Advances in this area would simplify the organization and accessing methods of 
a software base as follows. The specifications of each component would be 
transformed to canonical form before being entered into the software base. This 
can be visualized as a process of mechanically reducing the specification to a 
unique simplest form. The template for a query would also be transformed into 
canonical form before the physical retrieval is performed. This scheme would 
guarantee that a perfect match retrieval would always succeed if an appropriate 
reusable component was available, because it would eliminate the possibility 
that a retrieval would fail to find a module because it was specified in a way 
that is syntactically different from the retrieval template but semantically 
equivalent to it. Normal forms will also be investigated. Since a normal form is 
not necessarily unique, retrieval failures would not be completely eliminated by 
reducing specification and queries to normal form, but the hit ratio should be 
significantly improved. We propose to determine if canonical form specifications 
are practical, and if not, to seek normal forms with good hit ratios. 

Another area for investigation is the automated synthesis of a component in 
cases where the component is not available in the software base, but a small set 
of primitives that can be combined to form the required module is available. 
Limited logical inference techniques combined with heuristics for limiting the 
size of the space of building blocks will be investigated in the later stages of the 
proposed research, with attention to the use of the generalization hierarchy for 
limiting the size of the search space. 

2.4.2. Implementation Techniques for PSDL 

We also propose to investigate efficient methods for implementing flexible 
interpreters with restarting checkpoints. The efficiency criteria for a prototyping 
language are different than those for a programming language because 
modifications are frequent, and it is desirable to be able to run several different 
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modifications from the same point midway through a demonstration session. 
These considerations favor an interpretation strategy over a compilation stra- 
tegy. A strategy utilizing partially compiled and partially interpreted com- 
ponents, together with guidelines for triggering the automated compilation of 
components that are heavily used is promising. We propose to develop an 
experimental translator for PSDL, and to develop and evaluate several diiferent 
implementation methods. This process will be aided by an attribute grammar 
based translator generator[4]. 

One of the techniques currently used for meeting tight real-time constraints 
is multiprocessing. We propose to extend PSDL and the initially developed 
implementation techniques to multiprocessor implementations. The most impor- 
tant extension needed in the language is related to faithfully modeling schedul- 
ing constraints imposed by the implementation structure for the external sys- 
tems interacting with the real-time software. For example, it may be that two 
of the external systems are allocated to the same hardware and must have non- 
overlapping executions, or that the scheduling of some of the external events is 
already fixed, so that it must be treated as a constraint on the design of the 
real-time software rather than as a quantity to be derived in the prototyping 
process. Facilities for expressing this kind of information must be developed and 
integrated into the execution support system. This will be done by investigating 
real-time scheduling algorithms for multiple processor systems that respect the 
above mentioned constraints. 
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